Lambda the Ultimate

A beta version of the new Scala compiler (aptly named nsc) is now available. It's written in Scala and implements a new version of the language (aptly named Scala 2), which boasts some pretty tempting features:

• generalized package visibility rules (a small thing, but sorely missed in Java)
• a new mixin composition model
• a generalized implicit parameter mechanism to replace views (views always seemed like a slightly unfinished feature, a problem which seems to have been neatly solved)
• more flexible typing rules for pattern matching, effectively introducing GADTs

There are some other changes as well, but I expect implicit parameters and GADTs to get the most attention. Scala has been mentioned quite frequently lately, and I imagine quite a few people will want to take a(nother) look. In addition to the general information about this release, there's also a detailed description of the language changes.

Xavier Leroy's contribution to POPL'06 is Formal certification of a compiler back-end, or: programming a compiler with a proof assistant, which describes a fairly realistic mini-compiler from a subset of C, called Cminor, to PPC assembler.

So what? It's written entirely in Coq, which pretty much makes a certified compiler for free, and all done in a particularly easy way to leverage if you want to show particular implementations correct.

He's got a resource page up with the implementation (which he calls CompCert), and some further notes.

Impossible? Had we not designed compilers, operating systems, and document editors in small teams? And had I not repeatedly experienced that an inadequate and frustrating program could be programmed from scratch in a fraction of source code used by the original design? Our brain-storming continued, with many intermissions, over several weeks, and certain shapes of a system structure slowly emerged through the haze. After some time, the preposterous decision was made: we would embark on the design of an operating system for our workstation (which happened to be much less powerful than the one used for my rectangle-pushing) from scratch.

Download the PDF edition of this classic book today!

via Heiko Wengler in the discussion forum. (Thanks!!)

We’re at the point now with LINQ where we’re really starting to take a serious look beyond the language features, cool as they are, and pondering how these features are going to integrate with the UI. (It’s not like we haven’t thought about it at all, we have, but now we’re really taking a look at things end-to-end.) And so we started by coming up with a “language UI taxes” list that I’m shocked we haven’t put into a more concrete form until now. The various taxes that a language feature is going to have to pay include, but are not limited to...

What follows is quite a long list of things you have to think about designing the IDE.

I am one of those that think it is [o]ne of the wonderful things about working on a compiler... that... [y]ou don’t have any UI, but that doesn't mean, of course, that IDEs aren't here to stay...

We still have a long way to go, I think, in terms of understanding the subtle relationship between language features and IDEs (and vice versa). I wonder when this issue will enter the PL curriculum.

"What's New in Python 2.5"

Of interest are:

• Partial function application
• Metadata for Python Software Packages
• New Generator Features

If the Python crew is adding partial application to the language, I'm curious why they wouldn't have gone the whole hog and added in partial evaulation.

The X in XML stands for “Extensible”; one big selling point is that you can invent your own XML languages to help you solve your own problems. But I’ve become convinced, over the last couple of years, that you shouldn’t. Unless you really have to. This piece explains why. And, there’s a companion piece entitled On XML Language Design, in case you do really have to.

Ouch.

Java Subtype Tests in Real-Time. Krzysztof Palacz and Jan Vitek.

Dynamic subtype tests are frequent operations in Java programs. Naive implementations can be costly in space and running time. The techniques that have been proposed to reduce these costs are either restricted in their ability to cope with dynamic class loading or may suffer from pathological performance degradation penalizing certain programming styles. We present R&B, a subtype test algorithm designed for time and space constrained environments such as Real-Time Java which require predictable running times, low space overheads and dynamic class loading. Our algorithm is constant-time, requires an average of 10.8 bytes per class of memory and has been shown to yield an average 2.5% speedup on a production virtual machine. The Real-Time Specification for Java requires dynamic scoped memory access checks on every reference assignment. We extend R&B to perform memory access checks in constant-time.

I don't recall this paper or this subject being discussed here.

Also see this paper and this presentation.

Constraint Programming

I will not quote this introduction/manifesto/historical overview, as every page of it is worth reading.

It is not only a nice introduction into a promising field, but also a demonstration of how language design issues can be (to some extent) separated from high-level fundamental intuitions.

It is also quite interesting to follow the historical lines of the paper, it reads like an epic!

Ah, and by the way, that's the same constraint programming that underlies Oz.

(via Lemonodor)

This looks cool.

I am not sure about the details of how these bricks are to be programmed, but from the Slashdot dicussion is seems that there is some kind of dataflow language. Even more interesting is the claim that the VM is going to be documented, so third party language developers can target this low end robotics platform.

I have the pleasure of thanking ACM for granting permission to post the full texts of five ACM-copyrighted articles to the FORTRAN/FORTRAN II web site at the Computer History Museum. Here they are; for those already in the ACM Digital Library, we also link to the canonical ACM version via its DOI (Digital Object Identifier).

Once again we owe a big thank you to Paul McJones.